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MsR Redmond. "E 
Alan Gren, бита ‘Gunyan Mangus, Mark Резко. Bjame Steensgaard, David 


* Foundations of Software Engineering Group 
Wolfgang: 


< Operating Systems Group: 
Mart Aiken. Cris наме, Orion Hodson, Glen Hurt, Steve Lavi 


сиу and Dis 
* Dan Simon, Brian Zili 

* Software Design and Implementation Group. 

+ John DeTrevile, Ben Zom 

* Software Improvement Group. 

Manuel Fahndrich, James Larus, Sriram Rajamani, Jakob Rehof 

MSR Silicon Valley 

+ Marin Abd. Andrew Birel, Ufer Eringsson, Roy Levin, Nick Murphy, Ted 
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® Design parameters 
* scarce resources 
* benign environment 
* knowledgeable and trained users 
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| Changed 


Hardware and software industries were wildly successful 
* machines are fast 

* memory is cheap 

* computers are ubiquitous 

Malicious environment 

* ubiquitous worms, viruses, scams, attacks, 

Few users understand computers or software 


Microsoft 


• Goal: technology and techniques to build more 
dependable systems 
*  Dependable: predictable behavior and easily 
understood usage model 
* consumer satisfaction: new car vs. new PC 
* carhas.98to 999 availability (9-90 hours down timelyr) 
* Research on new OS, languages, and tools 
* attack problem from multiple directions. 
* working research prototype (not Windows replacement) 
*  Nomagic bullet 


* mutually reinforcing improvements to languages and 
compilers, systems, and tools 


Microsoft 


1 


2 


3. 


Pervasive use of safe (& analyzable) programming 
languages 

è type safety and memory safety 

* including device drivers, OS components, applications 
Improve system resilience despite software errors 
* failure boundaries between components 

* improve extension model 

* explicit error notification 

Increased verification 

* specification at multiple levels of abstraction 

* closed environments with explicit cross-domain interfaces. 
* design for verifiability 


Microsoft 


• Closed кете! 
channel * 95% writen in СВ. 
| + 17% of fles contain unsafe C$ 
+ 5% of fles contain x88 or C++ 
+ OS services & drivers in processes 
* kernel closed at boot time 
Software isolated processes (SIPs) 
+ all user code is verified safe 
+ зоте unsafe code in trusted runtime 
+ processes closed at start time 
‘Sate and efficient communication via 
strong тепасев 
“channels between processes 
channel behavior is specified & 
checked 


* checked behavior enables efficient 
‘Communication 


han mar. 
* Туре safety is crux of verification 
ana protector 
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Pervasive Safe Languages 


® Singularity is written in extended C# 
• actually Spec# 
(C# + pre/post-conditions and invariants) 
® Added features for systems programming 


® increase programmer control over allocation, 
initialization, and memory layout 


® Language design to support programming 
and verification 
® message passing 
® factoring libraries into composable pieces 
• compile-time reflection 
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| What About The Runtime? ET 


e JVM & CLR's design not always appropriate 
* rich runtime ("one size fits all") 
* monolithic, general-purpose environment 
* large memory footprints (-4 MB process for CLR) 
e many dependencies (CLR PAL requires >300 Win32 
ls) 


• JIT compilation 
* increases runtime size and complexity 
* unpredictable performance 

* replicate OS functionality 
* security, threading, configuration, etc. 
* moreisless 
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1 Singularity Runtime 


Е > 


Singularity Process 
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Singularity Runtime 


Libraries Singularity Process 


Bartok 
yi compiler 


Application 
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Singularity Runtime 


Libraries Singularity Process 


x86 
Executable 


Singularity 
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Singularity Runtime 


Singularity Process 
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istomizable Runtime 


Small execution environment 


ahead-of-timi iler (MSR Bartok) 
D зе me, global opti DELI compiler (! ) 


. ines се sn anne ere adi 
'ppicatiofitrary code 
+  factorable runtime and libraries 
Runtime, garbage collector, and libraries selectable on per- 
process basis 
* reduce memory and computation overhead 
* enforce design discipline and system policies per process 
Eliminate OS functionality from runtime 
* security, resource allocation, etc. 
Provide OS mechanism for enforcing system policy 
* runtime can constrain behavior (e g. driver environment) 


w Microsoft 


Singularity Runtime 


Singularity Process 
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Runtime Overhead 


Memory footprint 
“Hello World” process 


Singularity FreeBSD | Linux 2.6.11 | Windows 
5.3 (Red Hat FC4)| XP (SP2) 


C - static lib 232K 664K | 544K 
C++ - static lib 704K 1,216K 572K 
сё - w/ GC 3,750K 


• Сй process w/ GC has similar memory footprint to С++ 
* minimal process (no GC or exceptions) is ~16K 
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ne Resilience 


* Software errors should not cause 
system failure 
* Resilient system architecture 


* isolate system components to prevent 
data corruption 


* provide clear failure notification 


* implement policy for restarting 
failed component 
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Process Architectures 


Open Process Single Process 
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Open Process Single Process 
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_ Open Process Architecture 


® Open processes 


О 
• 


dynamic code loading and runtime code generation 
* DLL, Java class loading, browser plugins, device drivers in 
rnel, etc. 


cross-process memory sharing 
system API allows one process to alter state of another 


* Near ubiquitous (Windows, Unix, etc.) 


originated in Multics 


* Sharedstate reduces dependability 


85% of Windows crashes are caused by third party code in 
kernel 


interfaces between extension and host are often poorly 
documented and understood 


no isolation boundary between code and extension 
extension can access non-public interfaces (reflection) от 


| Single Process Architecture = 


All code and data in single address space <> 


* rely on language and memory safety to isolate components 
* dynamic code loading and runtime code generation 
= easy data sharing 


Xerox PARC (Cedar, Smalltalk, etc.) and Lisp Machine 
model 


* Java and МЕТ model as well 

Runtime is single point of failure 

® shared runtime must also meet all applications’ requirements 
Rely on garbage collection to reclaim resources 

* finalizers 

Difficult to constraint interactions. 


Microsoft 


Isolates And AppDomains Are Still Interdependent 


Microsoft 


ENSE 


Singularity Sealed Processes 


Singularity processes 
Proc Extension idc Tee 
Ка E Bp ee ee 
Bega 
Sa А 
FEES 
* extensions execute in 
ка 


* separate closed environments 
with well-defined interfaces 


OS Kernel ® no shared memory 
Process is fundamental unit 
of failure isolation 


Better: security, verification, 
failure handling, optimization 


Microsoft 


Static Benefit Of Sealed Processes 


Whole Reachable 


rogram Code Code ^ % Reduction 
Kernel 2.37 MB 1.29 MB 46% 
IDE Disk Driver 1.85 MB 455 KB 75% 
Web Server 2.73 MB 765 KB 72% 
Content Extension 2.14 MB 502 KB 77% 


ә Reduces process code size by up to 75%. 


ә Fewer code paths => better optimization & 
error analysis 


_ Need For 


* Existing processes rely on expensive hardware 
virtual memory and protection mechanisms 


* VM prevents reference to other processes' pages 


* protection prevents unprivileged code from access 
system resources (e.g. VM page tables) 


* Processes are expensive to create and 
schedule 
* encourages monolithic program development 
* large, undifferentiated applications 
* dynamic code loading 
* threading to allow independent control flow 


Lightweight Processes 


Microsoft 


Software Isolated Processes (SIPs) 


• Protection and isolation enforced by language safety and 
kernel API design, not hardware 


+ process owns a set of pages 

+ all of a process's objects reside on its pages (object space, not 
address space) 

* language safety ensures process can't create or mutate references 
to other pages 


* Global invariants: 
* по process contains a pointer to another process's object space 
* no pointers from exchange heap into process 


Microsoft 


cess Communications 


Interpr 


ә Channels are strongly typed (value and behavior), 
bidirectional communications ports 


* messages passing with extensive language support 

* Messages live outside processes, in exchange heap 
* onlyasingle reference to a message 

e "Mailbox" semantics enforced by linear types 


Microsoft 


Failure Isolation 


* SIPs are failure containers 
* no shared implementation or state across SIPs 
* process runtimes are distinct 

* OnSPP failure: 


* clean failure notification on peer 
channel endpoints 


* resources reclaimed by OS 


* Recovery feasible, not automatic 
or transparent 
* peers can recover and continue 


Microsoft 
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Trust Your System To A Type System? 


* Process integrity depends on type and 
memory safety 


* currently trust compiler and runtime 


e TAL can eliminate compiler from trusted 
computing base 


* Working on verifying the GC as well 
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Trust Your System То А Type System? 


* Process integrity depends on type and 
memory safety 


* currently trust compiler and runtime 


e TAL can eliminate compiler from trusted 
computing base 


* Working on verifying the GC as well 


Microsoft 


Micro Benchmarks 


Alon64 3000+ Cost (CPU Cycles) 

(вве лих 2 6.11 (Red | 

Forces SLI inquare, EZENN 
Minimum kernel - | Е: 
API call зо 0 зт | 627 
Message (LPC) 4,650 | 
requestireply 1,041 13,300 5800 | (NP) 6,340 | 
Process 1 4 | 
reca t EA 388,000 ШГ] 719,000 5,380,000 
e Why? 


e all SIPs run in ring 0 
* static verification replaces hardware protection 
* good optimizing compiler (not JIT) 
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® Integrate specifications throughout system 
* language 
ә interprocess communication 
* system configuration 
* Detect errors early, verify code late 
* language safety essential to system integrity 


В < = 
ти 
+ 


Es 
Microsoft 
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® Integrate specifications throughout system 
* language 
* interprocess communication 
* system configuration 
* Detect errors early, verify code late 
* language safety essential to system integrity 


— | | 
в== — Боже 
n 
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Ехатрје: 
Channel Contracts 


Zomble 


Sendony ) 


Example: 


Channel Contracts 


Contract 


public contract Tepconnectloncontract { 


itive connected : one { 
Read? > Weadtesu lt 
Write? “> writesesalt; 


GertocalAddress? -> IPaddressi -> 
‘Connected: 
GetkocalPort? -> Port! -> Connecte 


Donesending? -> весе чесну: 
Denegece ving? -> Sendoniy: 
Close? > Closed 

у А Заа 


state Reading 
atat connected; 
Nosoreotal -» sendonly; 
Remoteclose! ^» Zombie; 


“estati Ат tread; 


ase com. RemtectoseC) : 
fetum false; 


ins Specifications 


* Application is first-class abstraction 
with identity 


code + resources + manifest 


* Manifest specifies 


software components 

dependencies 

exported channels 

hardware or software resource requirements 
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Device Driver Specification 


requires 4MB frame buffer 
class s3Trio64config : Drivercategoryoeclan_(declared in PCI config) 


ToMemoryRange frameBuffer 
IoMemoryRange texteuffer 


requires channel to 
parent process for 
ToPortRange control; Dm 


TRef«Extensioncontract.Exp:Start» pnp; 


TRef«ServiceProvidercontract.Exp:Start» video; provides channel 
Е for clients to access 
Video device 


Specification Used In Many Ways 
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Specification Used In Many Ways 


Conflict 
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Specification Used In Many Ways 


1. Load driver 


Conflict 
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Specification Used In Many Ways 


Disk Driver 


class 
Mrary 


1. Load driver 


2. Allocate МО 
objects 


Conflict 
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Specification Used In Many Ways 


Load driver 


Allocate ИО 
objects 


Conflict Create 
channels 


Microsoft 


_ Verification Of System Configuration 


* Verification ensures 


* neverinstall an program that will break 
another program 


* never start a program without appropriate 
resources 


* never grant a program access to undeclared 
resources 


* Allofthese checks performed statically 


Microsoft 


Device Driver Specification 


Tequires 4MB frame buffer 
class s3triob4config : DrivercategoryoecTan. (decared in PCI config) 


IoMemoryRange frameBuffer 


IoMemoryRange texteuffer 


loPortRange control; enel 


TRef«Extensioncontract.Exp:Start» pnp; 


TRef«ServiceProvidercontract.Exp:Start» video; provides channel 
È for clients to access 
video device 


Singularity is basis for more 
dependable systems 


* pervasive use of safe programming languages 


* lightweight, closed, customizable 
run-time environment 


• verifiable specification of system behavior 
Working research prototype 

• driving research in large number of areas 
More information: 

* http://research.microsoft com/os/singularity 
* Growing number of TRs & papers 


Microsoft 


